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Fijeld of the Invention 
— i 

The present invention relates to a method of speeding up 
the registration procedure in a cellular network. 
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Prior Art 

The current wireless networks need a separate message to 
manage the connectivity to an external network, e.g. get 
connected to the network (PDP context activation), and to 
register, with a given application, e.g. the Session 
IntLtiatijbn Protocol (SIP) register procedure for the 
Votce over Internet Protocol (VoIP) or instant messaging, 
etp. This implies that two round trip delays (over the 
rajdio distance) (minimum are needed before the application 
bebomes available . 



In a cellular network, sending a packet does not only 
imply the physical transmission time of a packet over the 
radio, but also the time to establish radio resources. 
This time can be significant (seconds), as is known from 
the live network behavior of General Packet Radio Systems 
(GPRS) . 



30 



In addition, in a typical mobile terminal, the Packet 
Da :a Protocol (PDP) context is started when an 
application that may need this Packet Data Protocol (PDP) 
context is started. At this time this application already 
has the ^information it needs to register (even if the 
destination may be a logical name instead of an IP 
address) . 



35 



CONFIRMATION COPY 



WO 2004/016026 



PCT/IB2002/003030 



- 2/26 - 

The following two possibilities serve as examples. 

A backet Data Protocol (PDP) context may be established 
first, and then an application level message would be 
sent which however adds a second round trip delay over 
the radio distance. 

Another one is to send a Remote Authentication Dial-In 
Us|er Service (RADIUS) start message from a Gateway GPRS 
Subport Node (GGSN) when a Packet Data Protocol (PDP) 
context is established. However, this does not allow the 
mopile terminalj to send information which is specific to 
it (the mobile terminal's capabilities; the type of push 
service wanted; ' an instant messaging group to join; its 
signature; application settings etc.) and requires a 
pre-configuration of all application servers in the 
Gateway GPRS Support Node (GGSN) . 

Another important design criteria in a cellular network 
is to maintain the access network (e.g. of GPRS type) 
quite independent from the applications, so that new 
applications can be added transparently to the access 
network. 

Smjnmary |bf the Invention 

Th£refor|e, it is an object of the present invention to 
deal with the problems of the prior art, and to provide a 
method of speeding up the registration procedure in a 
cellular network. 

According to the present invention, this object is solved 
by providing a method of carrying an application level 
message encapsulated inside a signaling message of an 
, access network, said method comprising the steps of: 
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receiving an application level message from a sender 

application process to an access network signaling 

i 

prjocess; adapting said application level message and 
encapsulating it in a signaling message of an access 
nejtwork^ and delivering said encapsulated application 
le(vel message tb a receiver application process by 
tijansmitlting said signaling- message, wherein said 
encapsulated application level message is transparent to 
the means of said access network transmitting said 
signaling message. Advantageous modifications are defined 
in, the appended dependent claims. 



Hence one or many encapsulated application level messages 
are included in the Packet Data Protocol (PDP) context 

15 signaling (e.g. especially in the activation request), so 
thjat if the Packet Data Protocol (PDP) context is 
acpepted, gateway node means (e.g. the Gateway GPRS 
Support jNode (GGSN) ) will send the application level 
mefesage ion behalf of the mobile terminal to an 

20 application server (e.g. a Proxy Call State Control 

Fupctiorij (P-CSCF) ; a push proxy server (e.g. Wireless 
Application Protocol (WAP) gateway) or an instant 
messaging server) . 



25 In particular, the method according to the present 

invention allows with only one round-trip over the radio: 

• to establish one Packet Data Protocol (PDP) context and 
register in one or more application; or 

• to establish one secondary Packet Data Protocol (PDP) 
30 context and to send a ringing indication to the other 

party; or 

• j:o modify a Packet Data Protocol (PDP) context and 
Signal! the Quality-of -Service (QoS) change to the other 
£nd; o(r 
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• jto deactivate the Packet Data Protocol (PDP) context 
^nd de-register from an application. 

The present invention is presently considered to be 
5 particularly applicable to a Session Initiation Protocol 
(SIP) signaling, but also to other signaling such as a 
Resource Reservation Protocol (RSVP) signaling, or to a 
Point to Point protocol (PPP) signaling. 

10 According to the present invention, the registration 

procedure in general is speeded up. Moreover, the method 
according to the present invention is especially 
efficient to speed up a call establishment procedure for 
Voice over IP (VoIP) as it can be applied also when a 

15 ReLl-Tiire (RT) secondary Packet Data Protocol (PDP) 
cojitext is established. 

As a consequence, the delay is reduced. Further, the 
radio and the backbone is optimized by reducing the needs 
for radio signaling and reducing the number of packets 
sent. 



20 



30 



A key feature of the present invention is to maintain 
logical independence between the application layer (e.g. 
25 Slk or WAP - Wireless Application Protocol) and the 

access layer (e.g. GPRS). This independence is based on 
the fact, that the access layer does not need to 
understand application signaling. It only needs to know 
how to f forward it. Therefore, any new application could 
obtain the benefit of this functionality without further 
changes needed in the access layer. 



According to the present invention, the present object is 
further solved by providing a system adapted to perform a 
35 transmission of an application level message encapsulated 
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inside a signaling message of an access network, 
comprising: receiving means adapted to receive an 
application level message from a sender application 
process to an access network signaling process; adapting 
5 means for encapsulating said application level message in 
a Signaling message of an access network; and delivering 
means adapted to deliver said encapsulated application 
level message to a receiver application processing means. 

10 Brjief Description of the Drawings 

Further details of the present invention will become 
apparent from the following description of the preferred 
embodiments which is to be taken in conjunction with the 
15 appended drawings , in which: 

Fig. 1 shows a comparative example illustrating a VoIP 
signaling based on existing knowledge depicting a GPRS 
atjtach, a signaling for a Packet Data Protocol (PDP) 
2 0 context activation, a Proxy Call State Control Function 
(P-CSCF): discovery, and a Session Initiation Protocol 
(SIP) registration; 

Fijj. 2 sjhows another comparative example illustrating a 
25 VoIP signaling based on existing knowledge depicting the 
signaling foreseen to establish a call; 

Fig. 3 shows a Packet Data Protocol (PDP) context 
activation according to the present invention; and 



30 



Fig. 4 shows the encapsulated application level message 
information element according to the present invention. 
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Description of the preferred Embodiments 
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At first, reference is made to the comparative example 
depictecj; in figures 1 and 2, illustrating a current view 
of 



5 In 



VoIP [signaling based on existing knowledge. 



these figures, DNS denotes a directory name service, 
and DHCP denotes a dynamic host configuration protocol, 
while UE denotes a user equipment such as a mobile 
terminal. Other denotations are explained elsewhere in 
the present description. 



A rough count reveals a minimum of 25 messages over the 
radio distance including Radio Resource Control (RRC) 
messages which are not depicted here for a mobile 
terminal DE to fixed phone call, when starting with a 
15 turned off mobile terminal UE; and at least 40 messages 
ovar thes ; radio distance for a mobile terminal UE(A) to 
mobile terminal UE(B) call, if the called mobile terminal 
UE(B) is| not Radio Resource Control (RRC) connected. 

20 Fr&m this realization, it becomes clear why there is a 
need to optimize the delay. 



Itjis remarked that according to the present invention, 
as will be apparent from the description given below, a 

25 gain of four to five messages may be obtained over the 
radio distance, since Session Initiation Protocol (SIP) 
registration messages can be embedded in a Packet Data 
Protocol (PDP) context activation request/response, and 
" COMET "-/" 2 00OK" -messages can be embedded in step 19 (a 

30 secondary Packet Data Protocol (PDP) context activation 
reiuest/response) , while the ringing messages can be 
embedded in step 24 (secondary PDP context activation 
request)!. The details of embedding are described below. 
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A further gain can be achieved if there is a need to 
modify the bearer (step 33-38) or if the external 
resources reservation requires an end to end, i.e. mobile 
terminal to mobile terminal, signaling based on the 
5 Resource Reservation Protocol (RSVP) . 



10 



Next, reference is made to fig. 3 which shows a Packet 
Data Protocol (PDP) context activation as a preferred 
embodiment according to the present invention. 



Fiirstly,)- an application (inside the mobile terminal or in 
a separajte device such as a laptop) requests the mobile 
te:cminal| UE to initiate a Packet Data Protocol (PDP) 
context 'activation. In the same time, the application 

15 provides to the session management stack of the mobile 

terminal UE (this is the software in charge of activating 
the PDP context) an application level message. This 
application level message which is to be encapsulated may 
be a complete message such as a SIP registration message 

20 or a request to establish a WAP session. The mobile 

terminal UE adds the information provided by the 

application in an optional Information Element (IE) 
i 

which shall be called ''encapsulated application level 
message IE" in the PDP context activation request 

25 message. jj The thus encapsulated application level message 
is | then [transparently forwarded by the Serving GPRS 
Support Node SGSN to the GGSN in the Create PDP Context 
Recpues-c.!: Here, t^he term "transparently forwarded" implies 
that the optional encapsulated application level message 

30 information element is copied from one message to the 

other without being interpreted by the SGSN. This Packet 
Data Protocol (PDP) context may be a normal PDP context, 
a signaling PDP context or a secondary PDP context* 
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Secondly, the Radio Access Bearer (RAB) is set up. It 
should be noted that step 2 and 3 may be performed in a 
different order or even in parallel without modifying the 
id'ea of the invention. 



Thtlrdly, 



the Serving GPRS Support Node SGSN sends the 



Create p|dP Context Request message to the selected 
Gateway 'GPRS Support Node GGSN. According to the above, 
also this message includes the optional encapsulated 
10 application level message information element. 

When receiving the request, the GGSN will interpret the 
encapsulated application level message information 
element. The encapsulated application level message 
15 information element indicates which information should be 
sent to which destination address, i.e. a logical name or 
IP** address, and under which condition, for example, if 
thj3 Packet Data Protocol (PDP) context is accepted; if 
thfe Packet Data Protocol (PDP) context is accepted with 

20 th3 requested Quality-of-Service (QoS) (Here, the GGSN 
firstly processes the PDP context request normally. If 
th* output is tnat the PDP context is accepted (with the 
sane Quality-of iservice in option 2), it sends the 
application level message forward. If the PDP context is 

25 rejected, (or the Qulaity-of-Service is modified in 
option 2) the application level message is then just 
erased) if the response should be sent immediately or 
only when the application server response is received; 
etc. If the destination address is indicated as a logical 

30 name (e.g. "SIPproxy" or "WAPgateway" ) , the GGSN resolves 
a logical name from its configured data (e.g. Access 
Point Name (APN) configuration) or by querying the 
Directory Name Service DNS system. The GGSN extracts the 
content jfrom the encapsulated application level message 

35 ani forwards it, in step 4, to the application server by 
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using information sent in encapsulated application level 
message ^information element, and/or information coming 

: 

from the PDP context and/or information coming from 
configuration. Preferably , the GGSN uses the IP address 
of the Packet Data Protocol (PDP) context as source 
address . 



In a particularly preferred embodiment, the application 
level option includes a complete Session Initiation 

10 Protocol (SIP) message. The Gateway GPRS Support Node 
GgJsn just has to create the IP/UDP (User Datagram 
protocol) header, and to forward the message to the SIP 
proxy. The creation of the IP/UDP header is made by using 
information sent in an optional encapsulated application 

15 level message information element (for details, see the 
description related to figure 4), and/or information 
coining firom the j PDP context; (e.g. PDP type indication if 
IPv4 or IPv6 should be used; source address is the UE IP 
address) and/or information coming from a configuration 

20 (e ; .g. a destination address may be derived from logical 
name) . 



If the application level option indicated that the GGSN 
should send the Create PDP Context Response only when the 

25 application server response is received, the GGSN will 
start a timer to wait for answer. If a reply from the 
application server is received before the timer expires 
(s:ep 5)., this reply or part of it is copied into the 
application level option information element (IE) of the 

30 Create PjpP Context Response. If no reply is received 

before the timer expires, Create PDP Context Response is 
sept with an indication "server not answering". 



If the application level option indicated that the GGSN 
35 should send the Create PDP Context Response immediately, 
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step 5 is omitted and the GGSN sends a Create PDP Context 
Response. The reply from the server will naturally be 
sent to the IP address of the mobile terminal UE and be 
carried over to the PDP context as normal IP traffic. 

5 

in, step 6, the GGSN sends a Create PDP Context Response, 
containing an indication that the application level 
opltion has been understood. This indication may be a new 
application level option containing information returned 

10 by the application server, an indication that the 
encapsulated application level message has been 
successfully forwarded (e.g. cause "application level 
option successful"), or an error indication (e.g. 
"unknown logical name"; "unreachable destination 

15 address"; "invalid application level option format"; 

"server not answering"). This indication is coded as a 
new optional information element IE. 

in step 7, the SGSN sends the Activate PDP Context Accept 
20 containing the same indication received from the GGSN. 
The SGSN shall not interpret this indication, but only 
coU the indication received in the Create PDP Context 
Rejs ponsej: into the Activate PDP Context Accept message. 

25 When receiving the Activate PDP Context Accept, the 



mo 



ile terminal -UE informs its application process that 
the PDP context activation was successful and provides 
the indication to the application process. As mentioned 
earlier, this indication may be an application level 
30 option containing information returned by the application 
server, or an application level cause indicating success 
or failure. 

This indication is needed in order to support backward 
35 compatibility. The reason is that a mobile terminal UE 
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10 



cannot know if a network (i.e. both SGSN and GGSN) 

supports the feature as proposed according to the present 

invention. If the SGSN does not support the feature, the 

new optional information element IE as proposed will not 

be! forwarded to the GGSN. Therefore, the GGSN will behave 
i 

normally and not send back any indication to the SGSN 
about the application level. The SGSN is not sending any 
indication to the mobile terminal UE. Hence, the mobile 
terminal UE will also not pass any indication to the 
application process. The application will then know it 
has to resend its application as normal traffic (e.g. a 
IP/ODP/SIP packet over the established PDP context) . 



15 



20 



If the GGSN does not support the proposed functionality, 

i 

it; ignores the unknown optional information element IE, 
and correspondingly does not return any indication to the 
SGSN. TtjLe SGSN is not sending any indication to the 

bile terminal UE. Thus, the mobile terminal UE will not 



mo 



palss an| indication to the application process. The 
application will then know it has to resend its 
application as normal traffic (e.g. a IP/UDP/SIP packet 
over the established PDP context) . 



25 



Therefore, according to the above, if the SGSN or the 
GGSN does not support the proposed functionality, the UE 
and the application will behave as currently, even if the 
benefit of the proposed functionality is obviously lost. 
However, this kind of compatibility is an advantage of 
the present invention. 

Other alternative implementations are possible such as 
having a. full IP packet embedded in the session 
management (SM) signaling in the optional information 
element IE which would be good for the IP security 
35 protocol (IPsec) . It should be noted that this solution 
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wobld work in the Activate PDP Context Request message 
only if a static address is used, as the mobile terminal 
UE would not yet know its address. However, this 
alternative implementation can be used also with a 
5 dynamic address in all the other session management (SM) 
messages (e.g. Activate PDP Context Response; Activate 
Secondary PDP Context Request; Modify PDP Context 
Request) . Another option is to have only an Extensible 
Markup Language (XML) extension carried in the 
10 application level option information element between the 
mobile terminal UE and the GGSN that the GGSN will always 
fotward jto an application server by using a 
pre-configured protocol (e.g. the Session Initiation 



20 



Prptocol 



i p . The GGSN may also add an extension containing 
15 other information known about the user (e.g. a user 
identity such as MSISDN; Charging ID; APN used; IP 
address allocated; etc.). 



Encapsulated Application Level Message 

As a preferred embodiment of the present invention, it is 
proposed to change all session management (SM) messages 
by adding the new optional information element (IE). 

25 in! the following, the list of the concerned session 
management (SM) messages is given: 

• Activate PDP Context Request 

• Activate PDP Context Accept 

• Activate PDP Qontext Reject 

30 • Activate Secondary PDP Context Request 

• Activate Secondary PDP Context Accept 

• Activate Secondary PDP Context Reject 

• Request PDP Context Activation 

• Request PDP Context Activation Reject 
35 • Modify PDP Context Request 
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• Modify PDP Context Accept 

• Modify PDP Context Reject 

• Deactivate PDP Context Request 

• Reactivate PDP Context Accept 

5 

Specified below is the format of the "Activate PDP 
Context Request" according to the present invention. That 
is, specified are the changes to the existing knowledge 
as proposed by the present invention as an embodiment 
10 thfereof. Thus, an example of the format of the new 

information element according to the present invention is 
presented: 



15 



Activate PDP Context Request 

This message is sent by the UE to the network to request 
activation of a PDP context. 
See table below. 



20 Mebsage ; type 

i 

Significance 
Dipectiqn: 



ACTIVATE PDP CONTEXT REQUEST 
global 

UE to network 



Table ACTIVATE PDP CONTEXT REQUEST message content 
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IEI 


Infc 
Eleri 


>rmatipn j 
tent 


Type /Reference 


Presence 


Format 


Length 




Prot 
disc 


;ocol ! 

II i 
:riminator j 


Protocol 

discriminator 

10.2 


M 


V ! 


1/2 




Transaction 
identifier 


Transaction 

identifier 

10.3.2 


M 


V 


1/2 
3/2 




Activate PDP 
Context Request 
message identity 


Message type 
10.4 


M 


V 


1 




Requested NSAPI 


Network service 
access point 
identifier 
10.5. 6.2 


M 


V 


1 




Requjested j LLC SAPI 


LLC service access 
point identifier 
10.5.6.9 


M 


V 


1 




Requested QoS 


Quality of service 
10.5.6.5 


M 


LV 


12 




Requested PDP 
address 


Packet data 
protocol address 
10.5.6.4 


M 


LV 


3-19 


28 


Access point name 


Access point name 
10.5.6.1 


O 


TLV 


3 - 102 


27 


Protocol 

configuration 

oDtiions 


Protocol 
configuration 
options 10.5.6.3 


O 


TLV 


3 - 253 




Enca 
appl 
mess 


psulat 
icatic 
age 


,ed 

n level 


Encapsulated 
application level 
message 


O 


TLV 


3 - 1025 



The new information element IE as proposed by the present 
invention is marked in bold. 
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Description of the encapsulated application level message 

The purpose of the encapsulated application level message 

5 information element is to carry application specific 

information in session management (SM) messages, and to 

indicate to the GGSN which generic procedure to use. 



15 



Thb encapsulated application level message is a type 4 



10 in 



formation element with a minimum length of 3 octets. 
The maximum length for the information element IE is 1025 
octets. It is to be noted that the information element IE 
length restriction is due to the maximum length that can 
be* encoded by using 10 bits. 



The encapsulated application level message_inf ormation 
element is coded as shown in Figure 4. 

Below, the behavior of the Gateway GPRS Support Node GGSN 
20 is described in more detail. 

Wh£n the Gateway GPRS Support Node GGSN receives a 
session management (SM) message with an encapsulated 
application level message, it will first check: 

25 

1) Sending option conditions 

This field indicates the sending of the application level 
message : 

• "if the PDP context is accepted" , in which case the 
30 Gateway GPRS Support Node GGSN sends the application 

level message as soon as the Packet Data Protocol PDP 
context is accepted; 

• "if the Packet Data Protocol PDP context creation or 
modification is accepted with the Quality-of-Service 

35 (QoS) requested"; in which case the Gateway GPRS 
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Support Node GGSN sends the application level message 
only if the Quality-of-Service (QoS) requested by the 
mobile terminal UE was accepted unchanged (it is 
remarked that this may require a new indication from 
the Serving GPRS Support Node SGSN to indicate what was 
the Qvality-of -Service QoS requested by the mobile 
terminal UE) . If the Quality-of-Service (QoS) was not 
accepted as such, the application level option is 
ignored (the mobile terminal UE will detect the change 
and perform needed action such as sending the 
appropriate application level message) . 



2) Response option conditions 

This field indicates response options to the session 

15 management (SM) message: 

• "immediately"; in which case the Gateway GPRS Support 
Node GGSN sends the session management (SM) response 
jnessage immediately (but it may still wait for some 
other Isignaling such as RADIUS if applicable) ; 

20 • 'only jwhen application message response is received"; 
:he Gateway GPRS Support Node GGSN will prepare the 
session management (SM) response, but wait to receive 
the response from the application server. Based on the 
response of the application server, the Gateway GPRS 

25 Support Node GGSN will generate an encapsulated 

application level message which it will include in its 
own session management (SM) response. For example, this 
involves 

- reading the User Datagram Protocol (UDP) port 
30 and copying in appropriate encapsulated 

application level message field; 

- stripping away IP/UDP header; 

-I including the content of the User Datagram 
Protocol (UDP) packet in the encapsulated 
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application level message content field; as 
well as 

- using IP/UDP header info to properly set Port 
number to be used for sending • 
5 Note that this field is applicable only for a session 
management (SM) request message and not for a response 
message. 



3) The Protocol to be used for sending 
10 In case of: 

• iPv4/UDP: The Gateway GPRS Support Node GGSN will 
includ;e the encapsulated application level message 
content field in a IPv4/UDP packet; 

• IPv6/UDP: The Gateway GPRS Support Node GGSN will 
15 induce the encapsulated application level message 

content field: in a IPv6/UDP packet ; 

• IPv4 /TCP: The Gateway GPRS Support Node GGSN will 
include the encapsulated application level message 
content field in a IPv4 /TCP (Transfer Control Protocol) 

20 packet; and 

• IPv6/TCP: The Gateway GPRS Support Node GGSN will 
include the encapsulated application level message 
content field in a IPv6/TCP packet. 



25 Itj is remarked that it is one alternative to omit this 

field, so that the User Datagram Protocol (ODP) is always 
us 2d and, the Packet Data Protocol (PDP) type indicates 
IPv6 (Internet Protocol version 6) or IPv4 (Internet 
Protocol version 4) . 

30 

Another alternative is to have a more detailed indication 
such as that the Gateway GPRS Support Node GGSN will 
include the encapsulated application level message 
content field in a Session Initiation Protocol (SIP) 
35 register message over IPv6/UDP- 
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Still another alternative is that the address type 
indicates the lower level protocol: IPv4 or IPv6. 

5 It is remarked that other protocols may be indicated such 
asj L2TP/PPP (Layer 2 Transfer Protocol - Point to Point 
Prptocol) - 

4) Port Inumber to be used for sending 

10 The use 'of this port is to limit the need of a Gateway 
GPRS Support Node GGSN to know about the application 
protocol. So this field indicates to the Gateway GPRS 
Support Node GGSN if a fixed User Datagram Protocol (UDP) 
port is to be used (including the value) or if the User 

15 Datagram Protocol (UDP) port needs to be selected from a 
certain range. 

5) Setting the Traffic Flow Template (TFT) condition 
If: the mobile terminal UE indicates the destination 

20 address with a logical name, it cannot restrict the 

traffic for this Packet Data Protocol (PDP) context only 
fo:: this, destination address. Thus, this field is used to 
indicate, that only the traffic coming from the 
destination address (which is to be derived from the 

25 Gateway GPRS Support Node GGSN based on the logical name) 
on this Packet Data Protocol (PDP) context shall be 
allowed. It is remarked that the Packet Data Protocol 
(PDP) context signaling would be one use case for this 
feature. This field can have the contents: 

30 • Destination address type - This indicates if the 

address is a logical name, an IPv6 or IPv4 address; and 
• Application level option content - This field includes 
the actual content that the Gateway GPRS Support Node 
GGSN relays from the session management (SM) message to 

35 tjhe application level message it generates. In one 
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preferred embodiment, this is a Session Initiation 
|ProtOGol (SIP) message. 

Th!e invention is not limited to this format of 
5 encapsulated application level message. A simple 

implementation may be preferred where the GGSN behavior 
is simplified. For example, the GGSN may always forward 
the application message if the PDP context is accepted; 
it: may always wait a certain time for an answer from the 
10 application server. 



Besides, it is remarked that in the case where a mobile 
terminal UE is connected to a laptop, the mobile terminal 
UE could perform a similar function as the Gateway GPRS 
15 Sujpport Node GGSN. In this case, some fields which are 
nojt applicable should be ignored. 



Also the, format may be different in uplink and downlink 

|! : 

direction. For example, to simplify the behavior of the 
20 mobile terminal UE, the GGSN may still include the full 
message (i.e. including IP header) received by the 
application server in the response message as described 
above. But for the uplink, it may be more beneficial to 
not include the IP header, as the mobile terminal UE may 
25 not yet know its dynamic address at the time of sending 
the session management (SM) request and it may not know 
the real IP address of the application server. 

It; should be noted that this feature is specially 
30 advantageous for the network requested PDP context 

activation. This procedure is triggered by an IP packet 
arriving at the GGSN. Currently, the packet is stored in 
the GGSN and can be delivered to the mobile terminal UE 



over a normal PDP context only after a lot of signaling 
35 (including PDP context activation) . One of the problems 
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is that when the mobile terminal UE receives the Request 
POP Context Activation, it does not know which message 
has triggered the application. Thus, the mobile terminal 
UE has too little information to decide whether to 
5 activate a new PDP context or not. However, according to 
the present invention, the full IP message could be sent 
to the mobile terminal UE. Therefore, in addition to 
saving round trip on the radio, it also provides more 
information to the mobile terminal UE. That is, e.g. the 
10 GGSN encapsulates the message received by the server in 



15 



20 



the mess 



ca 



age called PDU notification sent to the SGSN. The 



Lied 



SGSN copies encapsulated information in the message 



Request j PDP Context Activation" and sends it to 



mobile terminal UE. 

It should be noted that the amount of encapsulated 
application level message should be recorded in the 
charging record. 

What is described above is a method of carrying an 
application level message encapsulated inside a signaling 
message of an access network, said method comprising the 
steps of: receiving an application level message from a 
sender application process to an access network signaling 



25 process; 



en 



adapting said application level message and 
=apsulating it in a signaling message of an access 
network;, and delivering said encapsulated application 
lelel message to a receiver application process by 
transmitting said signaling message, wherein said 
30 encapsulated application level message is transparent to 
the means of said access network transmitting said 
signaling message. 

Although it is described above what are the preferred 
35 embodiments of the present invention, it is apparent to 
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those skilled in the art that various modifications are 
possible without departing from the scope of the present 
invention as defined by the appended claims. 



